Sesión 4

Fecha: 07/03/2025

Hora inicio: 10:40

Hora finalización: 14:35

Lugar: Aula H1.12

Grupo 2

GastroStock

Ayuda a la gestión de inventarios de bares y mejora de logística mediante IA.

Feedback positivo de estudiante

• Inicio efectivo bueno.
• Han mejorado el logo.
• Muy buena presentación. Empiezan en orden, hablando brevemente en que consiste la aplicación.
• Muy buenas diapositivas. Tienen el texto justo y muchas metáforas visuales.
• Muy buena tabla de análisis de competidores pero no se entienden algunos iconos.
• Se ve muy bien todo. Tamaño de fuente muy bueno.
• Han ido cara a cara a reclutar cada usuario piloto, cercanía con el cliente.
• Buen desglose de trabajo para cada uno de los sprints

Feedback negativo de estudiante

• Parece que no tienen prototipo, muestran mockups.
• Solo tienen hasta ahora 13 usuarios piloto, lo cual quizás sea indicativo de algo.
• Notificación durante la presentación.
• No hay QR a landing page

Feedback de profesores (Cristina)

• No dio tiempo. Feedback de profesores (Pablo)
• No dio tiempo.

Grupo 3

EVENTBRIDE

Aplicación para gestionar eventos cristianos; bodas, bautizos y comuniones

Feedback positivo de estudiante

• Inicio efectivo muy bueno
• Usan la IA en el killer opener para recrear a un tal “ILLOJUAN”.
• Explica con un buen nivel de detalle los competidores.
• El análisis del coste es bastante exhaustivo
• Explican bien los problemas con las horas por persona y el reparto no equitativo de tareas
• Buena explicación del problema de subestimar las tareas y replanificación del sprint
• Buen Eslogan final.

Feedback negativo de estudiante

• No se han presentado
• Podrían haber introducido el video en la presentación.
• Lleva un papel durante la presentación. Sensación de inseguridad, de no haberse preparado bien.
• Mejor poner k para los miles en lugar de m, para evitar confusiones con millones.
• No se ve el prototipo.
• Han incluido el inicio de sesión o el registro, aunque, aprendiendo del feedback anterior, lo han obviado.
• El presentador va muy rápido.
• Meten el commitment agreement pero es innecesario.
• Dicen muchas veces, que para este problema ya hemos tomado medidas, pero nunca se comentan qué medidas se han tomado.
• Mientras ella expone, el otro presentador repasa con el papel.
• Se mueve mucho, está muy nervioso. Genera estrés.
• Hay diapositivas con mucho texto que no es legible desde largas distancias

Feedback de profesores (Cristina)

• Inicio efectivo tiene técnicas buenas: actual, llama la atención y relaciona el problema, pero acaba diciendo “hijos y toda la paranoia” que queda mal.
• Han abordado todos los puntos, pero iban muy rápido, muy acelerados.
• En el commitment agreement han puesto que todos los miembros han cumplido y esto es necesario ponerlo.
• No le convence mezclar la descripción del equipo con el rendimiento.
• La demo tiene problemas, no se puede leer. La letra está muy pequeña.
• La diapositiva 12, términos y condiciones, no hace falta ponerlo. No aporta nada.
• Retrospectiva: Quieren ver más información del rendimiento. Pregunta por los problemas resueltos.
• Las medidas tomadas, ¿son de prevención o soluciones para salir del paso?
• La traspa 23 no se lee. La fuente no le gusta porque junta mucho las letras. Poner menos información.
• Retrospectiva como análisis de cómo ha ido la semana e hilar con lecciones aprendidas.
• Poner fecha y plan de acción de usuarios piloto de manera clara.

Feedback de profesores (Pablo)

• De acuerdo con el punto 1.0 de Cristina, muy bueno para la asignatura, pero muy malo en un lanzamiento de producto.
• En el video, queda patente que los desarrolladores tienen talento creativo, pero lo criticado es el foco, hay que pensar en que se debe hacer un lanzamiento del producto.
• Traspa que tenga un tamaño de letra que no se vea: FAIL.
• Dicen que tienen particulares, de las 4X personas, si no son personas que van a hacer eventos, ¿qué hacen con la aplicación?
• Recomienda hacer una tipología de usuarios piloto. Dividir en este caso los usuarios pilotos por interesados en X evento.
• Le preocupa que diga que el texto es un apoyo, las transparencias NO son un apoyo, es un complemento que refuerza tu mensaje. No son unas notas del orador, es un reforzador, hay que ir todos a una.
• Metáforas visuales, muy necesarias para reforzar lo que se dice.
• No poner cifras exactas de euros, poner K.
• El tema de “la cosa es que ChatGPT no nos haga la aplicación” no es un problema y sería válido que lo hiciera, pero tienen que echar 50 horas. Si lo hacen todo en 1h, el resto hay que echarlo en otras cosas.
• Es interesante saber si se van a tomar medidas con las pull request a la hora de integrar.
• Es más importante la fase InReview que la fase Done.

Grupo 4

BORROO

Aplicación para generalizar el alquiler de objetos, es de matchmaking-improved market

Feedback positivo de estudiante

• Muy buen Killer opener, el mejor hasta la fecha.
• Muy buenos chascarrillos, además lo enlaza con la aplicación.
• De nuevo recuerda qué proporciona su aplicación con respecto a la competencia de forma visual.
• Estimaciones del coste muy claras, explica por qué dedica cada cantidad de dinero a cada ámbito del proyecto.
• Vídeo sobre la aplicación, muy buena idea.
• Pone ejemplos para explicar las métricas de trabajo, muy buena idea.
• Tiene talento para la exposición.
• Buena idea poner un gráfico burndown.
• Admite errores propios y es consciente de que tienen que cambiar algunas cosas.
• Muy visual las horas invertidas y el progreso alcanzado.

Feedback negativo de estudiante

• En el video de uso de la aplicación, no se ve todo, sería buena idea agrandar la página.
• Error en el video, más se ha acabado convirtiendo en un chascarrillo.
• Habla quizá demasiado rápido. Faltan pausas. Es una metralleta de información que puede saturar.
• Quizás sería mejor idea reducir la cantidad de información que quieres transmitir al público.
• Muchos ejemplos y casos concretos. No está mal meter unos pocos, pero tantos llegan a saturar.
• Lo importante, usuarios piloto, lo aborda de forma rápida.
• Repite mucho “de acuerdo?” y “de alguna forma”.

Feedback de profesores (Cristina)

• Presentación muy bien excepto por alguna transparencia mejorable.
• Inicio muy bueno pero un poco largo se le ha hecho.
• Algunos que según se ven en las tablas no parecen competidores.
• No se transmite la idea
• No es lo mismo la calidad del código que la calidad que se considere.
• No hay numero de pagina en alguna diapositiva
• Gestionar que es importante en la diapositiva. Imágenes muy grandes e irrelevantes.
• Dedicar mucho más tiempo a retrospectiva (40 / 50% del tiempo)

Feedback de profesores (Carlos Müller)

• Muy de acuerdo con Gabriel, tiene un gran dominio, pero habla rápido, aunque la dicción sea correcta y comprensible, peca de hablar demasiado rápido. Da la sensación de estrés, podría ser buena idea reducir el contenido de la presentación y resumir lo que es verdaderamente importante.
• Sugiere el lápiz en la boca para mejorar la dicción.
• Poner al principio, antes de la demo, decir que se presenta.
• Ve un problema con el copyright de Doraemon.
• Quizás Doraemon no sea la mejor opción, pues los más mayores no lo conocen y dan por hecho que sí. Si la presentación le llega a un camionero de avanzada edad, no entenderá el chiste.
• Cuidado con las preguntas al público asumiendo cosas.
• Costes: Falta plan de contingencia. Habría que poner K o M.
• Prototipo: Muy corto y se veía muy poco.
• Cuando ha fallado el video, deberían haber explicado cuál ha sido el error y no pasar rápido y corriendo a la siguiente diapositiva, da la sensación de no estar preparado.
• Dejar en claro las métricas que deben de seguir los QA para valorar la calidad.
• No invertir demasiado tiempo en reuniones.
• No han hecho enlace con los riesgos. ¿Se está aplicando los planes de contingencia?

Grupo 5

Camyo

App para juntar camioneros con empresas

Feedback positivo de estudiantes

• Buen killer opener, involucra al público.
• Utiliza chascarrillos que captan la atención.
• Muy visual la presentación, la letra cumple los requisitos de tamaño mínimo.
• Se nota que está muy preparado, no se ha dejado nada al azar.
• Muy visual la aplicación, se ha ilustrado en la presentación de manera que cada paso se vea en grande mientras se explicaba.
• Habla de previsión de riesgos y cómo han sufrido uno, comentan cómo lo solucionarán, buena práctica. (comunicación escasa entre backend y frontend, mal estimación del tiempo de tarea)
• Tiene un final con gancho.

Feedback negativo de estudiante

• Quizá un poco pesado los mockups definiendo cosas básicas como un registro o inicio de sesión. Trivial y pasable (Ajustar nivel de detalle).
• No me queda muy claro si lo que han enseñado es el caso de uso core u otra funcionalidad.

Feedback de profesores (Cristina)

• No se ha presentado los presentadores.
• No le queda claro si dan soporte a autónomos o no (responden que sí, y viene reflejado en la tabla de la presentación).
• Los usuarios piloto NO tienen fechas, quieren una agenda, ya sea con fechas absolutas o relativas, decir cómo reciben el feedback, cuáles son los tiempos de respuesta, cómo tratamos el feedback.
• No es necesario mostrar formularios como el registro. (mala elección de nivel de detalle). Centrarse más en los casos core.
• Retrospectiva: Se ha explicado bien en qué se ha dedicado el tiempo.
• Se queda corto la productividad del equipo solo con clockify y commits.
• Considerar otros criterios.
• Problemas y riesgos: Medición de cómo evolucionan los problemas. ¿Están abiertos, solucionados? Medición desde que se detecta hasta que se soluciona. Cómo medimos el problema hasta que se soluciona. Cualitativo o cuantitativo.

Feedback de profesores (Carlos Müller)

• Problema: No le queda claro qué es lo que les diferencia.
• No le ha quedado claro qué es la búsqueda de contratos. (Deberían haberlo explicado mejor, dado que da lugar a confusión).
• El inicio efectivo ha sido bueno, pero deben de buscar algo más relacionado con el tema, y a ser posible que esté estrechamente relacionado con su punto diferenciador; vender un boli está bien, pero no tiene nada que ver con los camiones.
• Se puede resumir la presentación del equipo. Invertir menos tiempo.
• Hay algún detalle como la barra de búsqueda que no se ve.
• Una demo grabada da menos sensación de mockup (responden que no tienen los botones todavía).
• Efecto cobra: recompensa por cada cobra muerta -> crearon granjas de cobras y acabaron pervirtiendo las métricas. Esto es un paralelismo a las métricas de análisis de horas.
• Buscas cualitativo antes que cuantitativo a la hora de valorar la productividad del equipo (alguien que haga pocos commits y luego ayude a la gente no será bien valorado).
• No se ven las leyendas de las imágenes.
• Le encanta la transparencia 25. Mezcla muy bien texto con iconos.
• Mucho tiempo sin apoyo visual en alguna transparencia.
• No han puesto de forma visual la replanificación y sería una buena idea.

Grupo 6

FisioFind

App para consultas de fisioterapia

Feedback positivo de estudiante

• Introducen con un buen killer opener, videos e imágenes que llaman mucho la atención. (bebés).
• Muy buena diapositiva del trabajo realizado. Muy visual.
• Ha bajado del estrado para exponer en otro nivel y así innovar con respecto a sus propios compañeros y el resto de grupos.
• Gráficas para mostrar el avance del proyecto y además las explica muy bien.​
• Buen chascarrillo para retomar la atención.
• Es buena idea un grupo de FAQ.
• Han pivotado de Taiga a Github Projects (han sabido rectificar).

Feedback negativo de estudiante

• Es raro empezar por los costes.
• Números de página MUY PEQUEÑOS.
• El presentador utiliza monótono, después de un presentador muy capaz, se queda en poco llamativo en el mejor de los casos.
• Serios problemas con el pase de diapositivas, el puntero no funciona y tienen que recurrir a miradas entre el pasador y el exponente.
• Quizás echo en falta que comience por la prueba funcional de la aplicación, estoy viendo usuarios piloto pero no me acuerdo ni de lo que hace la app.
• El nivel de detalle no es correcto, se habla del equipo demasiado en detalle, llevamos la mitad de la presentación y no hemos visto nada de la app.
• Utilizar el baremo de cantidad de commits u horas como parámetros es falsable y no mide realmente la calidad del trabajo.
• Si pasa tan rápido las diapositivas del equipo, ¿para qué ponerlas?
• Demasiadas diapositivas.
• Los gráficos tienen las líneas muy finas, la diapositiva está prácticamente en blanco.
• Muestran el MVP un poco tarde.
• Decir que está feo es echarse piedras. Mejor un comentario como “está en proceso”.
• No se ve nada de la aplicación. ENANO.
• Presentación muy larga. Se ha pasado de tiempo​ y no avanza más rápido a pesar de saberlo.

Feedback de profesores (Cristina)

• El killer opener máximo 1 minuto.
• El elevator pitch máximo 30 seg.
• El equipo muchas traspas y las han pasado muy rápido.
• Tienen problemas con el ratio de respuestas, podrían hacer una media de la satisfacción. (Dicen que se ha solventado a nivel de prioridad).
• Muchas transparencias.
• No se distinguían los problemas de los riesgos.

Feedback de profesores (Carlos Müller)

• Killer opener muy largo. Relacionarlo con el problema que resolvemos.
• Presentan los tres muy bien, pero Antonio debería mirar a todo el mundo, no solo a los profesores. Técnica de las 4 esquinas.
• Competidores: Ayuda mucho señalar de lo que se habla (destacarlo en la presentación).
• Se especializan en el mercado español, pero se llaman FisioFind. El profesor recomienda llamarlo FisioYa o TuFisio.
• Muy bien el tener en cuenta la estimación de suscriptores.
• La demo no se veía.
• Han personalizado bien el análisis de rendimiento.
• Uso de prompts.

Feedback general de final de clase

• Siguiente clase evaluación.
• 15 minutos para presentar.
• Asistencia obligatoria, test.
• Nueva píldora teórica.
• El contenido de la presentación no cambia.
• Se espera ver:
  • Killer opener 1 minuto.
  • Elevator pitch 30/45 seg.
  • Resumen del análisis de competidores.
  • Resumen de análisis de costes (concepto TCO, diferenciar capex y opex?).
  • Estimación a corto 4,6 meses (desde ya) y a medio 1,2 años de los gastos y los ingresos. Gráficas. Tres curvas: la pesimista, optimista y esperada. (ESTO NO SE PIDIO ANTES).
  • Situación actual respecto al total esperado (Seguimiento).
  • Ingresos, justificar de donde vienen y justificar a donde van.
  • En gastos: 3 curvas: Pesimista, optimista, esperada.
  • Equipo max 2 minutos.
  • La demo que se vea.
  • Pensar en formas más amenas de presentar la demo. Editar el vídeo, por ejemplo.
  • Demo con casos de uso core (15%?).
  • Retrospectiva:
    • Análisis de rendimiento de equipo 1 traspa con productividad y análisis del equipo.
    • Resultados automatización y análisis del código.
    • Problemas con su estado abierto, solucionado…
    • Lecciones aprendidas.
    • Medición: forma de saber si está funcionando el mecanismo de solución del problema.
  • Reloj del avance del proyecto (inversión respecto a esperado).
  • Medir la calidad del software.
  • Gestión de usuarios piloto:
    • No hace falta comentar cómo hemos captado los up.
    • Ya no nos centramos en la captación de usuarios pilotos, los que tenemos son los que son, estamos en el periodo de gestión. Cómo los gestionamos.
    • Cuántos tenemos.
    • Los roles que tienen.
    • Cómo nos comunicamos con ellos, cómo gestionamos su feedback, fechas…
    • Cómo se gestionan de cara al S2.
  • Necesitamos ya feedback de los up.
  • Planificación para el sprint 2.
  • Si afecta, planificación para el sprint 3.
  • Reporte del uso de la IA. Analicemos la salida.
  • Última diapositiva landing page.
  • Más la documentación de la failure conditions: Utilizar markdown no pdfs.